IBIS Macromodel Task Group Meeting date: 14 June 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: Ambrish Varma * Jared James Google: Zhiping Yang Intel: Michael Mirmak * Kinger Cai * Chi-te Chen Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara Ming Yan Radek Biernacki Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff Justin Butterfield Missouri S&T Chulsoon Hwang SAE ITC Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the June 7th meeting. Walter moved to approve the minutes. Jared seconded the motion. There were no objections. -------------- New Discussion: Supporting PI simulation in IBIS: Kinger said he had reviewed IBIS interconnect and EMD syntax to understand what elements could be incorporated into a PI modeling syntax proposal, per the discussions in the previous meeting. He listed 3 questions he had after reviewing existing syntax: 1. How are ground reference pins handled? - An important issue in setting up his problems is how to specify which of the GND pins is included in a port specification. 2. How can one set up a port amongst multiple POWER and GND pins. 3. How is it handled when one GND pin is included in more than one port's configuration? Kinger presented a simplified example scenario. He said a real system might have 400 BGA balls for which you want to create 20 to 40 ports. He presented an illustrative example with 4 ports. Arpad asked whether Kinger was talking about the reference terminal of a port, or a GND pin on the IBIS model. Kinger said he was asking how you could specify which GND pins from the Pin list are included in the reference terminal for a port created for the Touchstone file data. Walter said a bus_label is a property of an IBIS [Component]. It says, for example, that: - All of the VDD pins that have the same label could be treated as a single port in that particular IBIS component. - You can have 10 instances of that [Component] in an EMD Model, but that bus_label does not imply a short circuit connection between different Designators. - VDD is complex and may have many pins all over the place, but (for example) these 20 pins on the same bus_label on a [Component] are shorted and can be considered a single port. - Another 20 pins on a different bus_label with the same signal_name might have a small impedance relative to the first bus_label. Arpad said the only difference between signal_name and bus_label is that out of 15 pins on the same signal_name, you might want to break out 3 groups of 5 pins each on separate bus_labels. Arpad said one aspect that might be confusing is that at the EMD level signal_names are not automatically connected to identical signal_names in the [Components]. At the EMD level, signal_names imply electrical connections between EMD Pin List Pins and Reference Designator Pins that use the same signal_name. The EMD Model provides the model for the connection between them. Randy said one aspect of Kinger's question was about specifying individual references for the ports for a Touchstone file. Randy noted one shortcut assumption for the File_TS syntax. With File_TS syntax, an N port Touchstone file is listed with an N+1th terminal that provides a common reference for all ports. Randy said that if Kinger needs to specify a different reference for each port, then that can be handled by wrapping the Touchstone file in an IBIS-ISS subcircuit and using File_ISS syntax in the EMD model. Arpad again asked how the Touchstone data is being created. If you had a two plane model with a VDD plane and a VSS plane, when you connect the VRM to such a model are you connecting the positive terminal of the VRM to one port, the negative terminal of the VRM to a second port, and also providing reference terminals for each of the ports? Or, do you have a one port model (on the VRM side), and the positive terminal of the VRM connects to that port and the negative terminal of the VRM connects to the reference terminal of the port? Chi-te confirmed it was the latter, with the power and the local ground paths lumped into one port. Arpad said we are talking about a full loop inductance as opposed to a partial loop inductance approach. Walter said this was an example of the ground-relative approach to power-aware simulations. Arpad said that in Kinger's example, the green bga balls would be the negative terminal of the port. Kinger agreed. Arpad then concurred with Randy's earlier comment that the File_TS syntax only provides for a single terminal serving as the reference for all ports. Kinger wondered if we might add a 4th column to allow specification of a local reference for each port. Arpad noted that the Touchstone specification doesn't have a standardized way of defining port references. He said various tools provide different approaches via comments in the Touchstone file. Kinger said he would further review the concepts discussed in the meeting. He asked whether it would still be appropriate to define a new .spi file. He noted that we may have a common approach for interconnect, but their proposal still needs additional items such as the observation port, AC source information, and possibly an R-network in the future. Kinger agreed with Arpad and Randy that we should try to reuse as much as possible. Arpad said one thing we might consider adding is supporting multiple references for the Touchstone file with File_TS. Randy and Arpad said they didn't think this would be difficult to do. Bob noted that the .spi extension itself might cause confusion, as the name collides with some industry standard extensions for power aware simulators' file names. Bob asked that SNP_filename be changed to Touchstone_filename in Kinger's example syntax, as the SNP extension is not actually specified by the Touchstone standard itself and is just a common convention. - Curtis: Motion to adjourn. - Randy: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 21 June 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives